I was going to open an issue for this. Installation from script sites like greasefork and for styles as well like https://github.com/runxel/WikiSensei (button to install into Stylus by the end of the readme)

I will add the option as soon as I find/decide on the suitable popup.

@erosman
I'm wondering about auto-updates and this is related: none of the scripts I imported include @updateURL, so auto updates don't work. If I add the line manually, I presume it would get lost upon script update. So shouldn't FM store the URL separately from the script content itself and populate that "field" upon script install, if/when you implement this?

@Hlsgs
GM had a 2 step script update which I thought was not necessary. That meant having a JS and the actual script so script writer and/or host had to create a maintain an extra JS for each script (@updateURL & @downloadURL).

I attempted to simplify the process. It is up to script writer to add @updateURL. Creating custom settings for each script/CSS requires a lot of extra code and user-interface.

I didn't know about the extra JSON, but, if that's an established MO supported by all the dominant managers on both FF and Chrome, I doubt that the authors will bother with this, especially since they mainly care about Chrome. So, IMO, it would make much more sense to support said existing MO if you implement direct install.

All that beeing said, regardless of method, I've been thinking about script auto-update security and I wonder why other managers don't block auto-updates if they imply any change to the scripts' @match rules. Presumably, a dilligent user would audit these upon first install and would like to know if/when they change. Am I missing something here?

@Hlsgs The established MO has issues.

1- A separate file has to be created for each script by the script host
2- Extension has to get/download the meta.js from @updateURL check it and if the version is different than the script version then download the actual script from @downloadURL
FireMonkey does it all in one action.

GM4 has already made changes to the process. It initially didn't have the auto-update option. It seems to have been added (https://github.com/greasemonkey/greasemonkey/issues/2531) but the documentation doesn't show it yet (Metadata Block). It is in the old docs (updateURL) and shows the necessity of creating an extra file:
// @updateURL https://userscripts.org/scripts/source/scriptid.meta.js

💡 What I can do ......... is to alias @downloadURL and map it to @updateURL in FireMonkey since the actual script resides at @downloadURL and FireMonkey is not concerned with meta.js. That should enable FireMonkey to auto-update normal GM user-scripts.

All that beeing said, regardless of method, I've been thinking about script auto-update security and I wonder why other managers don't block auto-updates if they imply any change to the scripts' @match rules. Presumably, a dilligent user would audit these upon first install and would like to know if/when they change. Am I missing something here?

Sadly, that is true and open to considerable abuse. However, creating a system to identify and require confirmation by the users, is also not feasible during auto-update as it will results in many modal confirmation pop-ups which would interfere with browser performance and will be blocked by browser anyway.
There are many malware scripts around and users must be vigilant.

v1.19 @downloadURL/@installURL, if present, is used for Script/CSS update

You need to keep some data about installation URL:

Scripts posted to Greasy Fork will be rewritten in the following ways:

@updateURL, @installURL, and @downloadurl directives will be stripped, if present. The lack of these directives means that any script installed from Greasy Fork will be updated from Greasy Fork.

https://greasyfork.org/en/help/rewriting

All my scripts are like this.

@gwarser How does auto update work there?!

Is that against the MO of GM/VM/TM?

It's a way to make sure scripts are installed from vetted source. Otherwise version on Greasyfork may be safe (reviewed by many users), but from external @updateURL may be malicious.

How does auto update work there?!

All other script managers remember original source of the script and fetch from there.

Few links from GF forum:

https://greasyfork.org/forum/discussion/82/off-site-downloadurl
https://greasyfork.org/forum/discussion/comment/831
https://greasyfork.org/forum/discussion/116/issue-auto-updating-with-tampermonkey

It's a way to make sure scripts are installed from vetted source.

Actually, that is not the case. To start with, not all userscripts are vetted and then Greasyfork is not the only source for user-scripts.

All other script managers remember original source of the script and fetch from there.

That means due to the action of Greasyfork all script mangers must change their behaviour, create extra code to suit Greasyfork and make their established MO metadata block redundant!!

@Martii (openuserjs.org) is keeping the original format e.g. oujs - Meta View

I need to think about it and also further discussion/feedback is required on this issue.

Note: If security is the goal, @require creates a much easier method to pass malware.

Actually, that is not the case. To start with, not all userscripts are vetted

Of course there is no formal review process, but you can report bad scripts to moderators - such scripts will be removed. No way to do this for external updates.

That means due to the action of Greasyfork all script mangers must change their behaviour

Some managers did this before GF. I think there was use case to update from disk (back when browsers allowed it) for dev purposes. And many script authors just did not include this field in the header.

(openuserjs.org) is keeping the original format e.g. oujs - Meta View

Are you sure it's kept when pointing to third-party source?

Note: If security is the goal, @require creates a much easier method to pass malware.

Only whitelisted sources are allowed: https://greasyfork.org/en/help/external-scripts

Check historical versions of metadata wiki page:

https://wiki.greasespot.net/index.php?title=Metadata_Block&action=historysubmit&type=revision&diff=7462&oldid=7461

Notes added under @downloadURL and @updateURL in 2015:

It is unusual to specify this value. Most scripts should omit it.

And in 2017 source was commented out (removed from view) in "reorganization":

<!-- 4.x does not use this
=== @downloadURL ===

The URL to download this script from, when installing updates.

<pre class='sample'>// @downloadURL https://www.example.com/myscript.user.js</pre>
 
Greasemonkey's default settings require this value to be secure (<tt><nowiki>https://...</nowiki></tt>) for updates to be applied.
If it is not specified, the URL the script was originally installed from will be used.

It is '''unusual''' to specify this value.
Most scripts should omit it.

-->

<!-- Not supported by 4.x
=== @updateURL ===

The URL that Greasemonkey will download when checking for script updates.

<pre class='sample'>// @updateURL https://www.example.com/myscript.meta.js</pre>

This URL need only contain the metadata block.
This value ''may'' be specified relative to the URL the script itself is downloaded from.

If the [[#@version|@version]] specified here is newer than the installed version, an update will be offered to the user.

It is '''unusual''' to specify this value.
Most scripts should omit it.

-->

Source: https://wiki.greasespot.net/index.php?title=Metadata_Block&action=edit&oldid=7489

bulb What I can do ......... is to alias @downloadURL and map it to @updateURL in FireMonkey since the actual script resides at @downloadURL and FireMonkey is not concerned with meta.js. That should enable FireMonkey to auto-update normal GM user-scripts.

Why? It was huge issue on server side. Even explained in doc you linked.

I need to think about it and also further discussion/feedback is required on this issue.

Let's see what is the feedback from other users.

This is all a bit above my head, but, what I can add is that, GreasyFork having been made with the explicit purpose of providing safe userscripts, it's the only repository I trust and use. Other scripts I write myself. So, supporting GFs model of updates, which only updates from GF itself and not external sources, is a definite must for any manager I would use.

The @require whitelist, which I didn't know about, only confirms my trust in GF, even if I always audit these manually.

Only whitelisted sources are allowed: https://greasyfork.org/en/help/external-scripts

Just for info: It is a good step which makes them safer but it doesnt make the scripts safe. Beside trackers such as GA, many older version of libraries have security issues (like JQ 1-2, Angular etc0 and there are allowed.

💡 once direct instal is added, I can add the original source, if @updateURL @downloadURL are missing.

• The question would be should it be limit to GF or everywhere?

• Furthermore, should direct install be allowed for GF or everywhere? That means any userscript located anywhere which allows installation of scripts from github or other servers.

GF could have rewritten the @updateURL @downloadURL to GF script URL which would have made it a lot simpler!!!

@erosman

v1.19 @downloadurl is now converted to @updateURL and ***.meta.js is ignored for @updateURL

Not a wise idea since you might be enabling DDoS possibilities which could get a CVE/CERT against your extension and could probably be taken down (TM almost got one from me when a recursive update check happened on OUJS but I chose to work with him first to get it fixed as I understand TM's role/importance across all the browsers). It's best if you just leave it the way its supposed to be and don't tinker with it. As always there is at least two sides to that coin toss. You will probably trigger a DoS protection with this decision and a requestor will be banned for a very long time on OUJS with the causal factor being FM which can in turn prompt a CVE/CERT (TDN) for you... hence the DDoS.

That meant having a JS and the actual script so script writer and/or host had to create a maintain an extra JS for each script

Not true at all... but can be a choice for some if they choose it for better script management.

Most scripts should omit it.

That is because most people didn't use the correct values on USO, and also when Anthony rewrote it from sizzles routine he changed it quite a bit in later GM3. He also put a routine in that disables the request header if it failed in GM3. As you stated GM4 doesn't use them at all because it's probably too complicated to code in the extension by some over there, but hopefully his code now only reads only what it needs and terminates the connection if enough info is retrieved... however the bulk of the other .user.js engines still do at last look including GM Port, TM, and I believe VM. Regardless of the state of any other .user.js engine, including GM Port, the "least common denominator" is what we will use. i.e. @updateURL is where to check for an update and @downloadURL is where to get the update... both can be the same value at this point in time on OUJS (unless in certain cases in lockdown). If they are both omitted GM3 era will use the installation source .user.js for both as a default which is currently the only migration that happened in GM4.

As far as OUJS goes if it's absent and we go into lockdown no script source will be served period for that script without the proper keys when using OUJS. I've been contemplating doing lockdown full time since we have an interface that properly shows the @updateURL and @downloadURL values, for OUJS, to use if it continues to be an issue with the .user.js engine managers.

GF could have rewritten the @updateURL @downloadurl to GF script URL which would have made it a lot simpler!!!

I agree somewhat provisionally... however GF is gently violating copyright CA and DMCA by knowingly rewriting on a publishing site without legal authorization (proper licensing)... binary/interpreter execution is different with that particular legal issue. Comments are just as copyrightable too. However his current methodology allows a master site (take GH for example) to host the unadulterated source .user.js and present it on both OUJS and GF but he also has a more DoS attacks than we do usually. So it's a matter of perspective I think.

@gwarser

It's a way to make sure scripts are installed from vetted source. Otherwise version on Greasyfork may be safe (reviewed by many users), but from external @updateURL may be malicious.

...

Only whitelisted sources are allowed

These are some of Jason's goals with good intentions however it's monopolistic/fear oriented in nature and doesn't allow for the features that were originally put in. e.g. a remote repository for any presentational sites i.e. OUJS (and even USO back in the day) tries to keep things as decentralized as possible (within reason) and allows more flexibility than GF which is centralized. As with all sites .user.js can be good or it can be evil. Even if @updateURL, @downloadURL, @resource and @require were all forward unsupported it's still just as easy to xhr to a script source on an evil target. i.e. in my book the GF stripping is not a viable solution because there's always another way to do "evil" deeds and ~"manual auditing" is what you should be doing always at any experience level.

The choice is up to the end user... be oblivious/ignorant with a centralized only system, or be smarter and learn how to be decentralized.

Of course there is no formal review process

Unless someone wants to pay everyone for doing this there is the review and report/flag on both OUJS and GF as a more viable process and its free.

(openuserjs.org) is keeping the original format e.g. oujs - Meta View

Are you sure it's kept when pointing to third-party source?

What? 😕 oujs - Meta View only shows what we return if it's called. If a user uses GH as the primary master site (for @updateURL and @downloadURL) these retrieved values aren't utilized because they aren't OUJS. The meta routine is meant to be short, quick, brief, less regulated and overall better for everyone's bandwidth and coding skill level. i.e. you don't have to wait until the terminating UserScript metadata block line in order to terminate/close the request because you know it's already as short/quick as possible.

Todays quote for this topic:

"The road to hell is paved with good intentions" * WikiPedia ref

@Martii Thank you for taking the time and your feedback. I do need and appreciate the feedback in order to decide where to go from here. 👍

@updateURL is where to check for an update and @downloadURL is where to get the update... both can be the same

That is somehow what FM does now i.e. "both can be the same"
FM (v1.19 not released yet) in practice only uses @updateURL.

• If a userscript only has @updateURL, then that value is used.
• If a userscript has both @updateURL & @downloadURL, then @downloadURLvalue is used.

Not a wise idea since you might be enabling DDoS possibilities

This part, bearing in mind above, I didn't understand.

Overall, what would be the best approach (even if that is not the common practice)?

@erosman

Take a look at item 3 at https://openuserjs.org/about/Frequently-Asked-Questions#q-does-openuserjs-org-have-meta-

If @updateURL and @downloadURL are the same URL then the .user.js engine manager should always be required to send the header if it's checking for updates. If it detects an update then it sends another request using the @downloadURL with the request normally. i.e. plain GET with no additional headers.

If @updateURL is absent in a .user.js then the default is to try @downloadURL with the header. Anthony modified this in GM3 due to USO's frequent outages and made it also check the full script source i.e. without the header but the one critical failure that wasn't anticipated is that it never checked with the header again until reset. Failures include internet outages i.e. GM wouldn't get a response so it would pull full source and would fail to send the header on successive checks until reset thus causing USO to degrade rapidly. There was also a third party involved (MITM) around that time that he used that I, and others, wasn't real happy about due to tracking concerns. He claimed it would help but it actually was a severe privacy/security issue. He eventually got rid of it due to blocking in some regions and the negative backlash.

if @downloadURL is absent then absolutely use the install source from the original install. Keep in mind there is the original key name is @installURL. We "upmix" to current @downloadURL spec but we still support scripts that used the original key name.

I have been "pushing" the actual meta url route on our site to prevent any possible .user.js engine manager issues because it will only return the minimized metadata block i.e. the bare minimum needed (the top text area window of oujs - Meta View).

When TM had a massive recursion issue it was doing both meta routine checks and full script source url downloads but recursively (over and over for the same script) on the same machine thus causing a DDoS and killed our site a few years back. When we go into lockdown it's initial reasoning is an attempt to mitigate possible issues in the extensions/addons. Our limit is 1MiB and if a user has multiple scripts installed that is a multiplication of that on bandwidth vs. a small amount of bytes for just the meta routine. Also if you request too many .user.js files from our site and ignore the response headers the user using your extension may get banned for a DoS attempt i.e. the blame will be on the .user.js not OUJS. GF has similar DoS protection although may not be a long time ban. Ours could potentially be over a month if it detects continual abuse... so those users who install other peoples scripts too won't be able to update and FM will be causing potentially more security issues including our mitigated DoS prevention.

Btw if you are going to transform keys for whatever reason you might reconsider ignoring @include and @exclude with regular expressions when you copy them to the matches value in Fx. (from my original visit with FM) which is perfectly acceptable since re's only came in the GM3 era and persist with some .user.js engines... GM earlier and everything else around that era just ignored them. Yours fails to install the script because you aren't ignoring them which is the golden rule of thumb. i.e. "If a key is not understood it is ignored". Anyhow... sidebar on this topic... but loosely related to your stated transformation.

If a userscript only has @updateURL, then that value is used.

If an Author is using the meta.js only URL route then you'll potentially be updating to a 4 line script with no actual script content. Thus "disabling" the script and they'll have to go hit our site again to reinstall from scratch. They probably won't be happy with this extension forcing them to do this, possibly incurring additional charges.

If a userscript has both @updateURL & @downloadURL, then @downloadURL value is used.

This is where you can cause a DoS and banning... if someone sets both to the .user.js route then you may end up hitting the source route twice. Multiply that times the number of scripts someone has installed and you may hit our DoS prevention limit and end up banning those users from our site. Again I'm sure they won't be happy with that and this extension. If you aren't stopping at the closing UserScript comment then you are in effect wasting peoples bandwidth again. The metadata block may be anywhere in the file, however it is strongly and recently, recommended to be near the top of the file. Some other pre and post parsers also need to be at the top as well (think linters) so GM's spec flexibility is required for compatibility across the board.

Anyhow hope some of this makes sense to you. I have to go since I'm not feeling well today.

@Martii Thank you for the feedback and sorry that yo are not feeling. For later, when you feel better.....

If an Author is using the meta.js only URL route then you'll potentially be updating to a 4 line script with no actual script content.

That is not the case.. since as mentioned, .meta.js is ignored and if it exists and there is also @downloadURL, then @downloadURL is used.
FireMonkey NEVER updates to .meta.js

This is where you can cause a DoS and banning...

Again, that is not the case. Besides the fact that Auto-Update is disabled by default AND there is an auto-update interval setting in FireMonkey in days (so the shortest is once a day) AND the recommendation in Help advising user NOT to enable Auto-Update globally and explaining the reason ............................................. FireMonkey also throttles auto-update and it is currently set to 10 auto-updates at a time. Auto-updates are done at browser idle time.

If you aren't stopping at the closing UserScript comment then you are in effect wasting peoples bandwidth again

True... but then doing it via 2 sources also wastes bandwidth and affect browser performance by making more HTTP requests. The bandwidth usage in modern internet is negligible. Most scripts are quite small and very large scripts, IMHO, should be avoided as they affect browser performance anyway.

there is the original key name is @installURL.

I will update the code to cover it.

engine manager should always be required to send the header if it's checking for updates

Not a fool-proof method and can lead to errors unless a set of pre-agreed headers are created and sent by the servers on request (which is often not possible unless the site has adequate control of the server).
Servers may not send the correct Last-Modified headers for these script as they are often kept and served from databases.
Last-Modified dates for each installed script will conflict with Last-Modified of the original script after manual edits to the script.

@erosman

but then doing it via 2 sources also wastes bandwidth and affect browser performance by making more HTTP requests.

Most ppl don't need to do the 2nd call unless there's an update so it is the most efficient method available. Generating a connection is the least of everyone's worries in this case. Transferring on a slow connection is more important and if one is roaming then it can cost more if an extension pulls full source not to mention the DB overhead (that also can be a potential DoS caused by your extension. Don't try to deny this because this is a fact that I'm well aware of on multiple sites). It is your job to prove it otherwise and not just give an uncited/unclear statement. You clearly haven't been in the updating business very long. If you were around on USO several updaters were shut down for DoS... please don't be one of them.

Regardless of your trying to justify it because you think it isn't correct, it is the correct way and was put together by several very smart and some wise people.

If your extension causes any DoS/DDoS on our site you won't make any of us happy either (This includes GF). You also risk UserScripts as a whole by giving the ones more ammo as to why UserScripts are only evil. Your extension will never be listed on our site because of your ignoring one of the golden rules of ignoring lines it doesn't understand. You gave me a b.s. answer when I first was invited here about how Fx doesn't do regular expressions with WebExtensions. When I dug into your code and the spec it was actually you who didn't bother to ignore any value that contained the re. A very simple conditional would fix that. This is an unfortunate circumstance even if you seem to think that your extension isnt' a .user.js engine manager (CSS hasn't even been touch in my conversation but is acknowledged) but there are some basics to always apply when you use the UserScript metadata block. This extension still has promise but I wouldn't recommend this extension at this time... some of it is due to your asking for advice but then turning around and throwing it back in everyone's face saying it's ~"too complicated". (I've watched your conversations for quite some time). I'm starting to get that vibe myself from you. I'm getting rather disappointed and definitely being made to feel like I'm wasting my time here. :(

For example:

Not a fool-proof method and can lead to more compilations.

It is the defacto standard of a well established methodology. You just told everyone in the HTTP1.0/1.1/2.0 groups that headers are a fools errand and that everyone in the IETF/IANA is "too complicated". Headers are normal to use. You are just being lazy as you implied beyond this quotation by not coding for it. If you expect to support automatic updates you have to at least make an effort to conform to some standards and ethics.

... Furthermore, it requires keeping a lastmodified/Last-Modified ...

I stopped reading in-depth about here... and my first unfettered thought is "Deal with it! Don't be lazy and say it's wrong just because you don't want to code for it". With all complex systems there are patterns, you ignore quite a few of them atm. Every updater goes initially into "check mode" with @version and not the JavaScript equivalent of mtime (CPP reference) so I'm not even sure why you posted this sentence. We don't even set the lastmodified in meta.js I think... it's all @version value.

Anyhow... I'm still not feeling well so I'm being extremely literal myself so apologies but this is the vibe that I'm getting from you. Perhaps it's just best if we postpone this conversation at least until I feel better so I won't be as literal which can lead to negative reciprocation trends if you don't understand my communication bluntness.

@Martii
I invited feedback for constructive discussion. It seems that you have turned into personal attacks.

Lets now talk frankly.

Your assumption of DDoS (Distributed Denial of Service) attack is very short-sighted and self-serving. A DDoS can be carried out with bites of data and can generate 1000s of connections per second.

Requesting GET from a web-site is not DDoS and most modern commercial servers can handle 1000s of requests per second. Even the limitation of DB servers such as MySQL is at a minimum 250 simultaneous connections.

I was a server admin when internet speed was dial-up and DSL was a dream and DoS attacks were all too common.

Please don't not call the low-spec server capabilities and inability to handle traffic as DDoS. They are not the same.

FireMonkey makes 10 auto-update at a time (if enabled), in an async sequence. A server that can not handle 10 connections is not really a viable server. Anyone calling 10 connections from a user DDoS is simply out-of-date by a few decades. A normal web page makes 100s of connections. Image sizes are now in many MBs. Facebook as an example makes practically many 100s of connections. A thumbnail web page album can make 100s of connections for a single page load. Pages that have over 10mb of data are just a normality in today's internet.

This is 21st century and not 1980s.

The headers are often filtered by many servers. Furthermore, servers using DB backbend will not have flat files so getting Last-Modified header is not an option.

I was trying to avoid having to explain these basic things. When I said too complicated, I meant complicated to explain to people in laymen's language.

You are also adamant that what you are saying is the absolute truth and I have never seen you back down for the over 10+ years that I have known you. I was being courteous by not refuting what you had said, even though they were meaningless.

I shall in future refrain from involving you and/or requesting feedback from you as I am only looking for constructive feedback and not personal and rather rude attacks.

Please do not post here any more.

To cut the LONG story short.......

I made FireMonkey for my own use as I wanted an alternative.
I released FireMonkey in case others might also find it useful.

Users have the prerogative to chose if they want to use FireMonky or not. I gain nothing financially if they do.

Wow... shortly after my post, vindictive reviewer has made a 1 star review for FireMonkey making false claims about FireMonkey as a retaliation.

After making personal attacks in this thread, he has continued to make the same pedantic personal attacks as extension review.

He continues then on to make an "Abuse Report"... just wow

Just for the concern of the real users:

https://greasyfork.org/en/help/meta-keys
@updateURL, @installURL, @downloadurl
Describe how user script managers should get updates. Greasy Fork will strip these keys, which makes any script installed from Greasy Fork only update from Greasy Fork.

There is no meta.js in Greasy Fork set up. Script update has to check the actual script by all user-script managers.
He claims in the reviews that checking the actual script (GET the script) equals to DDoS.

He further claims.. CA, DMCA violation etc etc ... and whatever he could throw in the pot to vent his anger.

If any real user have any queries, I am happy to answer them.

Once again, FireMonkey is a NEW type of Script & Style manger. It has never claimed to be a clone of GM/VM/TM or Stylish/Stylus.

FireMonkey has attempted to make the transition less cumbersome by adopting most common practices in GM/VM/TM, as clearly outline in its Help document.

This is where you can cause a DoS and banning... if someone sets both to the .user.js route then you may end up hitting the source route twice. Multiply that times the number of scripts someone has installed and you may hit our DoS prevention limit and end up banning those users from our site

An example of making assumptions without understanding the code....

FireMonkey only uses ONE URL for updates. Stating "if someone sets both to the .user.js route then you may end up hitting the source route twice" demonstrates the act of making assumptions not based on fact and without understanding.

DDoS is 1000s requests per second. Making 10 request in a row (not per second) does not constitute or result in DDoS.

It is the defacto standard of a well established methodology. You just told everyone in the HTTP1.0/1.1/2.0 groups that headers are a fools errand and that everyone in the IETF/IANA is "too complicated". Headers are normal to use. You are just being lazy as you implied beyond this quotation by not coding for it. If you expect to support automatic updates you have to at least make an effort to conform to some standards and ethics.

Another example of lack of knowledge or understanding...

here is an example:

https://greasyfork.org/en/scripts/4294-antiadware

Version   1.42.1
Created   2014-08-17
Updated   2017-12-16

Here is the result of HEAD request from
https://greasyfork.org/scripts/4294-antiadware/code/AntiAdware.user.js

Processing: 1
access-control-allow-origin: *
content-encoding: gzip
content-length: 37382
content-type: text/javascript
date: Tue, 05 Nov 2019 10:48:43 GMT
etag: "5dc146e9-9206"
last-modified: Tue, 05 Nov 2019 09:54:49 GMT
server: nginx/1.14.0 (Ubuntu)
strict-transport-security: max-age=31536000
x-firefox-spdy: h2

Read the last-modified which shows the date of today 05 Nov 2019 and not the date of script update which was 2017-12-16

I stopped reading in-depth about here... and my first unfettered thought is "Deal with it! Don't be lazy and say it's wrong just because you don't want to code for it".

One should not making assumption not based on facts. It is important to check the facts first and then make a judgment.

v.1.19 Added Web Install option for greasyfork.org

and my first unfettered thought is "Deal with it! Don't be lazy and say it's wrong just because you don't want to code for it".

Right back at you ............... "Deal with it! Don't be lazy and say it's wrong just because you don't understand or like it".

But most importantly... I advise checking the code before making claims to avoid making frivolous statements.

Anyone who has checked the code would know how uninformed those comments are.

FireMonkey is FREE ..
Making demands and then threats, slander, defamation and libellous actions are inappropriate.

The best way to get the software to suit your demands is to get/pay someone to make it for you.

There is an adage that says, "Don't look the gift horse in the mouth"

Example from OpenUserJS
https://openuserjs.org/scripts/laidbacktempo/EasyVideoDownload

Source metadata block

// @updateURL   https://openuserjs.org/meta/laidbacktempo/SaveFrom.net_helper.meta.js
// @downloadURL https://openuserjs.org/install/laidbacktempo/SaveFrom.net_helper.user.js

Trying both above URLs and result is useless for updating

v1.9 Added Direct Install option for files loaded into tab for https://greasyfork.org/scripts/*.user.js & file:///*/*.user.js